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SUMMARY 


For  the  past  decade,  different  agencies  throughout  the 
Department  of  Defense  (DoD)  and  industry  have  been  involved 
in  the  development  of  unmanned  ground-vehicle  systems. 

Most  of  these  vehicle  systems  were  designed  to  meet  certain 
requirements.  Communications  interoperability  between 
systems  was  not  one  of  these  requirements. 

As  the  effort  to  develop  unmanned  vehicle  systems  matures 
and  increases  in  magnitude,  communications  interoperability 
between  the  different  systems  has  become  very  desirable. 
This  is  because  systems  which  can  talk  to  each  other  have 
the  potential  to  allow  flexible  testing  in  the  development 
phase,  and  to  make  possible  more  effective  deployment  of 
these  systems  once  they  are  mature  enough  to  be  fielded. 

In  the  spring  of  1987,  an  effort  was  begun  to  determine 
what  would  be  required  to  make  it  possible  for  different 
robotic  vehicle  systems  to  talk  to  each  other.  At  the 
time,  many  unmanned  vehicles  had  been  built  by  DoD.  All, 
however,  could  talk  only  to  the  dedicated  control  station 
that  they  were  exclusively  designed  for. 

It  was  determined  that  the  most  efficient  way  to  achieve 
interoperability  would  be  through  the  adoption  of  a  set  of 
communication  protocols.  The  Open  Systems  Interconnection 
Reference  Model  (OSI-RM) ,  developed  by  the  International 
Standards  Organization  (ISO) ,  was  chosen  as  the  general 
framework  from  which  to  choose  and  develop  protocols.  The 
OSI-RM  is  a  model  of  a  computer  communications  architec¬ 
ture.  It  was  developed  to  promote  compatible  communica¬ 
tions  among  a  wide  variety  of  digital  systems.  The  OSI-RM 
describes  seven  distinct  layers  that  define  the  functions 
involved  in  communicating. 

The  U.S.  Army  Tank-Automotive  Command  Research,  Development 
&  Engineering  Center  Technical  Report,  "Robotic  Vehicle 
Communications  Interoperability,"  number  13387,  dated 
August  1988,  relates  each  of  the  seven  layers  to  robotic 
vehicle  communications.  In  the  report,  a  message  format  is 
proposed  for  one  of  the  layers. 

This  report,  "Robotic  Vehicle  Message  Format,"  is  a  follow¬ 
up  to  report  number  13387.  Based  upon  comments  and  sugges¬ 
tions  from  the  different  organizations  actively  involved  in 
the  DoD  robotic  vehicle  communications  interoperability 
effort,  the  message  format  proposed  in  report  number  13387 
has  been  extensively  modified. 

This  report  describes  the  modified  message  format,  labeled 
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the  robotic  vehicle  message  format  (RVMF) .  The  RVMF  will 
be  implemented  on  unmanned  ground  vehicle  testbeds  which 
are  currently  being  developed.  The  RVMF  will  be  thoroughly 
tested  on  these  vehicle  systems,  and  all  necessary  modifi¬ 
cations  will  be  made.  The  resulting  revised  message  format 
will  then  be  proposed  for  standardization  for  use  on  future 
development  and  production  unmanned  vehicle  systems. 
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1.0 


INTRODUCTION 


This  technical  report,  prepared  by  the  Robotics  Division  of 
the  U.S.  Army  Tank-Automotive  Command  (TACOM) ,  describes  a 
message  format  protocol  which  will  be  used  by  Army  robotic 
vehicle  systems.  Use  of  this  protocol  is  one  of  the  steps 
which  will  be  taken  to  ensure  communications  interoperabil¬ 
ity  between  new  robotic  vehicle  systems. 

This  protocol  will  be  extensively  tested  on  the  robotic 
vehicle  testbeds  being  built.  Based  on  these  tests,  the 
protocol  will  be  revised  and  upgraded  so  that  it  provides 
the  performance  required  and  desired.  Once  fully  de¬ 
veloped,  tested,  and  proven,  the  protocol  will  be  used  as 
the  standard  for  the  robotic  vehicle  systems  which  will 
eventually  be  fielded. 


2.0.  OBJECTIVES 

The  two  goals  of  this  effort  were: 

•  To  develop  a  protocol  which  could  be  used  on 
current  robotic  vehicle  systems  to  make  communi¬ 
cations  interoperability  possible. 

•  To  begin  working  towards  a  standard  protocol 
tor  robotic  vehicle  systems  which  will  be  field¬ 
ed. 


3.0.  CONCLUSION 

The  Robotic  Vehicle  Message  Format  ( RVMF)  described  in  this 
report  provides  the  functionality  needed  in  a  high-level 
protocol  for  robotic  vehicle  systems  and  subsystems. 


4.0.  RECOMMENDATIONS 

Recommend  that  those  agencies  involved  in  the  development 
of  robotic  vehicle  systems  or  subsystems  implement  the  RVMF 
in  order  to  be  compatible  with  Army  systems,  and  also  to 
provide  input  to  help  define  the  protocol  standard  for 
future  Army  robotic  vehicle  systems. 


5.0.  DISCUSSION 

The  Open  Systems  Interconnection  Reference  Model  (OSI-RM) , 
developed  by  the  International  Standards  Organization 
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(ISO) ,  is  used  as  the  general  framework  to  achieve  communi¬ 
cations  interoperability  between  different  robotic  vehicle 
systems.  The  OSI-RM  is  not  a  protocol  standard.  Instead, 
it  specifies  seven  distinct  layers  that  define  the  func¬ 
tions  involved  in  communicating. 

One  advantage  of  the  OSI-RM  is  that  all  the  layers  are 
modular.  This  allows  protocols  for  different  layers  to  be 
developed  individually,  and  then  be  brought  together.  The 
remainder  of  this  report  will  describe  a  message  format 
that  will  be  used  as  one  of  the  seven  layers,  the  presenta¬ 
tion/application  layer. 

The  RVMF  is  depicted  in  Figure  5-1.  Each  field  of  the  RVMF 
will  be  described  in  the  following  sections.  These  fields 
are  referenced  by  their  descriptive  names. 

5.1.  Field  Descriptions 

5.1.1.  Message  Length.  This  field  has  a  length  of  one 
byte  (eight  bits).  It  is  used  to  determine  the  length,  in 
bytes,  of  the  entire  message,  including  the  message  length 
byte  itself. 

5.1.2.  Submessage.  This  is  the  grouping  of  all  the 
control  commands  or  status  information  that  have  the  same 
Block  Address  and  Unit  ID. 

5. 1.2.1.  Submessage  length.  This  field  has  a  length  of 
eight  bits.  It  is  used  to  determine  the  length,  in  bytes, 
of  the  entire  submessage,  including  the  submessage  length 
byte  itself. 

5. 1.2. 2.  Destination  Address.  The  Address  field  is  made 
up  of  two  fields,  the  Block  Address  and  the  Unit  ID.  Each 
field  has  a  length  of  eight  bits. 

The  Block  Address  identifies  the  category  to  which  the 
control  command  or  the  status  message  belongs.  The  many 
different  control  commands  and  the  status  information  that 
are  and  will  be  needed  have  been  grouped  into  categories 
based  on  function.  Each  of  these  categories  has  been  given 
a  number,  which  is  represented  by  the  Block  Address. 

The  Unit  ID  is  used  to  represent  a  particular  unit  which  is 
in  the  category  identified  by  the  Block  Address.  The  Unit 
ID  is  required  because  there  may  be  multiple  units  within  a 
single  Block  Address.  Section  5.2  describes  the  Block 
Address  and  the  Unit  ID  in  greater  detail. 

For  example,  there  is  a  category  represented  by  a  particu- 
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Figure  5-1.  Robotic  Vehicle  Message  Format  (RVMF) 


9 


4  HITS  B  BITS 


lar  Block  Address  called  "mono  video  source”.  The  Unit  ID 
is  used  to  differentiate  between  the  forward  driving  cam¬ 
era,  the  rear  driving  camera,  the  peripheral  cameras,  and 
the  reconnaissance  camera. 

5. 1.2. 3.  Source  Address.  This  is  a  sixteen-bit  field 
which  describes  the  place  a  message  originated.  The  bytes 
can  represent  a  Block  Address  and  a  Unit  ID,  as  in  the 
Destination  Address  field  (section  5. 1.2. 2.)  ,  or  the  bytes 
can  represent  an  arbitrary  number  assigned  by  the  source. 

When  a  message  which  requires  an  acknowledgment  is  re¬ 
ceived,  the  Destination  Address  and  the  Source  Address  are 
switched.  Now  what  was  formerly  the  Source  Address  is  now 
the  Destination  Address.  This  guarantees  that  the  proper 
module  is  acknowledged. 

5. 1.2.4.  Transaction.  The  Transaction  Held  represents 
the  actual  information  that  is  to  be  transmitted.  It 
consists  of  four  fields.  Each  is  described  below. 

The  Sequence  Number  is  a  four-bit  field.  It  is  used  to 
identify  the  acknowledgment  returned  against  the  original 
message. 

The  Transaction  Type  is  a  12-bit  field.  It  describes  the 
information  type,  and  defines  how  the  recipient  should 
treat  the  information.  The  Transaction  Type  is  made  up  of 
two  fields,  the  Transaction  Disposition  field  and  the 
Transaction  Category  field. 

The  Transaction  Disposition  is  a  four-bit  field.  it  is 
used  to  give  the  status/purpose  of  the  particular  transac¬ 
tion,  for  example, if  the  transaction  is  initiating  a  mes¬ 
sage  exchange,  or  responding  to  another  message. 

The  Transaction  Category  is  an  eight-bit  field,  it  de¬ 
scribes  the  message  type,  such  as  a  control  command  requir¬ 
ing  or  not  requiring  an  acknowledgment. 

The  different  transaction  dispositions  and  categories  are 
listed  in  section  5.3. 

The  Attribute  is  an  eight-bit  field  that  consists  of  an 
Attribute  Identifier  and  a  Parameter  Bit. 

The  Attribute  Identifier  is  a  seven-bit  field,  it  identi¬ 
fies  the  control  command  or  the  status  information  that  is 
being  conveyed.  Attribute  Identifiers  are  further  dis¬ 
cussed  in  section  5.2. 
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The  Parameter  Bit  field 

is 

one  bit  long. 

It  is  used  as  a 

binary  parameter.  A  one 

or 

a  zero  in  the 

Parameter  Bit 

field  is  used  to  depict 

one 

of  the  two  conditions  in  the 

following  situations: 

Parameter  Bit  value 

One 

Zero 

On 

Off 

Open 

Close 

Lock 

Unlock 

Left 

Right 

Lower 

Higher 

in 

Out 

Limit  As  Set 

Range  Limit 

Default  Limit 

Range  Limit 

Zero 

Bit 

For  example,  il  the  transaction  is  a  control  command,  and 
the  attribute  field  identifies  that  the  headlights  are  to 
be  controlled,  then  the  Parameter  Bit  would  declare  the 
desired  state  of  the  lights:  a  one  for  lights  on,  or  a 
zero  for  lights  off. 

If  a  command/status  message  cannot  be  depicted  by  a  binary 
state,  the  Parameter  Bit  field  is  set  to  zero  and  is 
ignored . 

The  Parameter  field  contains  the  attribute  data.  For 
example,  if  the  transaction  contained  status  information, 
and  the  attribute  identified  that  the  status  was  the  engine 
temperature,  then  the  parameter  field  would  consist  of  the 
number  which  represented  the  temperature.  The  length  of  the 
parameter  field  is  uniquely  defined  by  the  Block  Address, 
Unit  ID,  Transaction  Type,  and  Transaction  Attribute.  Due 
to  the  use  of  the  Parameter  Bit,  not  all  attributes  require 
a  parameter  field.  For  attributes  that  do  require  the 
parameter  field,  however,  there  will  always  be  the  required 
number  of  parameters.  The  Addendum  shows  which 
control/status  messages  require  the  parameter  field,  and 
the  length  (number  of  bytes)  of  each.  Section  5.4  de¬ 
scribes  parameter  representations. 

5.2.  Block  Address ,  Unit  ID ,  and  Attribute  Identifier 

5.2.1.  Explanation.  These  three  fields  are  used  to 
uniquely  identify  any  function  that  is  to  be  performed,  or 
any  status  information  which  is  to  be  conveyed.  As  previ¬ 
ously  stated,  the  Block  Address  identifies  the  category 
from  which  the  control  command  or  the  status  message  be¬ 
longs,  the  Unit  ID  is  used  to  represent  a  particular  unit 
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which  is  in  the  category  identified  by  the  Block  Address, 
and  the  Attribute  Identifier  identifies  the  particular 
control  command  or  status  information. 

Use  of  the  Unit  ID  provides  a  regularity  to  the  numbering 
of  units  of  the  same  type.  If  at  a  later  time  an  addition¬ 
al  gun,  camera,  etc.  needs  to  be  added,  it  will  use  the 
same  block  address  as  the  other  gun,  camera,  etc.  Also, 
this  simplifies  the  software  which  must  send  the  different 
commands  to  the  proper  subsystems. 

5.2.2.  Listing.  The  Addendum  lists  the  different  Block 
Addresses,  Unit  IDs,  and  Attribute  Identifiers  which  have 
been  identified  thus  far,  and  the  numbers  which  represent 
them. 


5.2.3.  Expansion.  The  Block  Address  and  the  Unit  ID 
fields  are  each  eight  bits  in  length,  and  the  Attribute 
Identifier  is  seven  bits  long.  This  means  that  the  Block 
Address  field  can  be  used  to  identify  up  to  256  (2°)  cate¬ 
gories;  the  Unit  ID  field  can  be  used  to  identify  up  to  256 
units  per  category;  and  the  Attribute  Identifier  field  128 

( 2' )  particular  messages  per  unit. 

If  more  than  256  different  Block  Addresses  or  Unit  IDs  are 
needed, these  fields  can  be  expanded  to  two  bytes.  An  FFH 
in  either  field  is  used  to  indicate  that  the  next  byte  is 
an  extension  of  the  field. 

5.3.  Transaction  Types 

5.3.1.  Field  justification.  This  byte  is  used  because 
there  is  a  great  deal  of  commonality  between  many  of  the 
transactions.  This  will  allow  like  transactions  to  be 
treated  the  same.  This  field  will  simplify  software  as 
well  as  the  usage  of  the  protocol. 

5.3.2.  Transaction  Dispositions.  There  are  five  transac¬ 
tion  dispositions. 

5. 3. 2.1.  Initiating.  This  is  used  when  the  message  is 
initiating  a  communication  exchange,  not  responding  to 
another  message. 

5. 3. 2. 2.  Command  received.  This  is  used  to  verify  that  a 
message  sent  that  required  an  acknowledgment  has  been 
successfully  received.  It  is  also  used  when  a  command  is 
in  the  process  of  being  executed,  but  execution  is  not  yet 
complete. 


5. 3. 2. 3.  Command  executed.  This  is  used  to  verify  that  an 
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action  described  by  a  control  command  and  requiring  an 
acknowledgment  has  been  successfully  completed. 

5. 3. 2. 4.  Command  unknown.  This  is  used  to  indicate  that  a 
command  that  was  received  is  unknown,  and  therefore  no 
action  will  result. 

5. 3. 2. 5.  Command  execution  failed.  This  is  used  to  make 
known  that  an  action  described  by  a  control  command  that 
was  sent  has  not  been  successfully  completed.  This  type  of 
transaction  will  always  have  a  one-byte  Parameter  field, 
which  can  be  used  for  a  code  which  describes  the  reason 
that  the  command  failed. 

5.3.3.  Transaction  Disposition  Codes.  Following  are  the 
bit  patterns  for  each  disposition  type. 


Initiating 

0 

0 

0 

0 

Command 

received 

0 

0 

0 

1 

Command 

executed 

0 

0 

1 

0 

Command 

unknown 

0 

0 

1 

1 

Command 

execution  failed 

0 

1 

0 

0 

5.3.4.  Transaction  Categories.  There  are  14  transaction 
categories. 


5. 3. 4.1.  Control  with  acknowledgment.  This  indicates  that 
the  message  is  a  control  command  that  requires  an  acknowl¬ 
edgment  to  verify  that  the  command  was  either  received  or 
completed. 

5. 3.4.2.  .Control  no  acknowledgment.  This  indicates  that 
the  message  is  a  control  command  that  does  not  require  an 
acknowledgment  to  verify  that  the  command  was  either  re¬ 
ceived  or  completed. 

5. 3. 4. 3.  Status  request.  This  indicates  that  the  message 
is  requesting  that  particular  status  information  be  provid¬ 
ed  . 

5. 3. 4. 4.  Periodic  status  request.  This  indicates  that  the 
message  is  requesting  that  particular  status  information  be 
provided  periodically. 

5. 3. 4. 5.  Query  control.  This  asks  if  the  command  identi¬ 
fied  by  the  Address  and  the  Attribute  is  available  on  the 
vehicle. 
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5. 3. 4.6.  Set  alarm  limits.  This  is  used  when  the  message 
will  set  alarm  limits.  If  the  Parameter  Bit  is  set  (one) , 
the  alarms  will  be  set  to  the  default  limits,  and  the  two- 
byte  Parameter  field  will  be  ignored.  If  the  Parameter  Bit 
is  not  set  (zero),  the  lower  alarm  limit  will  be  set  to  the 
number  represented  by  the  first  byte  in  the  Parameter 
field,  and  the  upper  alarm  limit  will  be  set  to  the  number 
represented  by  the  second  byte  in  the  Parameter  field.  It 
is  possible  to  use  a  Parameter  field  with  a  length  greater 
than  two  bytes.  The  software  will  determine  the  Parameter 
length  based  on  the  Block/Unit  ID/Attribute. 

5. 3. 4. 7.  Query  alarm  limits.  This  is  used  to  determine 
what  certain  alarm  limits  are. 

5. 3. 4. 8.  Set  operating  limits.  Used  to  set  the  operating 
limits  of  the  function/ subsystem  identified  by  the  Destina¬ 
tion  Address  and  Attribute  fields.  If  the  Parameter  Bit  is 
set  (one) ,  the  operating  limit  will  be  set  to  the  default 
limits,  and  the  two-byte  Parameter  field  will  be  ignored. 

If  the  Parameter  Bit  is  not  set  (zero) ,  then  the  lower 
operating  limit  will  be  set  to  the  number  represented  by 
the  first  byte  in  the  Parameter  field,  and  the  upper  oper¬ 
ating  limit  will  be  set  to  the  number  represented  by  the 
second  byte  in  the  Parameter  field. 

5. 3. 4. 9.  Query  operating  limits.  This  query  is  used  to 
determine  the  operating  limits  of  the  function/ subsystem 
identified  by  the  Destination  Address  and  Attribute  fields. 

5.3.4.10.  Indication.  This  is  used  when  the  message  will 
provide  some  status  information  that  was  not  solicited. 

5.3.4.11.  Alarm  activated.  This  is  used  to  indicate  that 
an  upper  alarm  limit  has  been  exceeded,  or  vice  versa  for  a 
lower  alarm  limit.  There  are  two  types  of  alarms:  1) 
Attribute  alarms,  and  2)  Device  alarms. 

An  attribute  alarm  is  used  when  an  attribute  of  a  unit  is 
in  a  dangerous  or  alarm  condition.  A  device  alarm  is  used 
when  the  device  itself  is  in  an  alarm  condition.  For 
example,  if  the  engine  oil  pressure  (oil  pressure  is  an 
attribute  of  the  engine)  were  too  low,  an  attribute  alarm 
would  be  sent.  On  the  other  hand,  if  an  engine  died  out 
for  an  unknown  reason,  a  device  alarm  would  be  sent. 

An  attribute  alarm  has  the  code  for  the  particular 
attribute,  which  is  in  an  alarm  condition,  in  the  Attribute 
Identifier  field.  The  first  byte  of  the  parameter  field 
represents  the  value  of  the  attribute,  and  the  second  byte 
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gives  the  applicable  error  code. 

Attribute  alarm  limits  are  either  set  prior  to  the  opera¬ 
tion  of  a  system,  or  they  can  be  set  using  the  "set  alarm 
limits"  Transaction  Category. 

Device  alarms  are  indicated  by  a  zero  Attribute  Identifier 
field.  An  alarm  dictionary,  which  for  each  device  identi¬ 
fies  the  different  alarms  and  corresponding  alarm  codes,  is 
needed.  These  alarm  dictionaries  are  out  of  the  scope  of 
this  report. 

5.3.4.12.  Alarm  retired.  This  Transaction  Category  is 
used  when  an  alarm  condition  which  caused  an  "alarm  acti¬ 
vated"  to  be  sent  no  longer  exists. 

5.3.4.13.  Command  execution  indication.  This  Transaction 
Category  is  used  by  the  sender  to  notify  the  recipient  that 
the  "control  with  acknowledgement"  transaction  previously 
reported  as  "command  received"  has  now  been  completed 
successfully. 

5.3.4.14.  Command  failed  indication:  This  Transaction 
category  is  used  by  the  sender  to  notify  the  recipient  that 
the  "control  with  acknowledgment"  transaction  previously 
reported  as  "command  received"  has  failed.  A  one-byte 
parameter  field  can  be  used  as  a  failure  code,  the  same 
codes  as  those  used  in  the  "command  execution  failed." 

5.3.5.  Transaction  Category  Codes.  Following  are  the  bit 
patterns  for  each  category  type. 


Control  with  acknowledgment 

0000 

0001 

Control  no  acknowledgment 

0000 

0010 

Status  request 

0000 

0011 

Periodic  status  request 

0000 

0100 

Query  control 

0000 

0101 

Set  alarm  limits 

0000 

0110 

Query  alarm  limits 

0000 

0111 

Set  operating  limits 

0000 

1000 

Query  operating  limits 

0000 

1001 

Indication 

0000 

1010 

15 


Alarm  activated 

0000 

1011 

Alarm  retired 

0000 

1100 

Command  execution  indication 

000  0 

1101 

Command  failed  indication 

0000 

1110 

5.3.6.  Set  up.  Transactions  which  start  the  dialogue 
between  the  initiator  and  the  recipient  have  zero  in  the 
Transaction  Disposition  field.  Responding  transactions  use 
the  same  Transaction  Category  as  the  corresponding  initiat¬ 
ing  transaction.  The  Transaction  Disposition  will  be 
dependent  on  the  result  of  executing  the  initiating  mes¬ 
sage. 


5.4.  Parameter  Representations 

5.4.1.  Parameter  Types.  There  are  three  types  of  parame¬ 
ters  which  can  be  used:  Numeric  (N) ,  select  (S) ,  and 
proportional  intensity  (PI) .  The  type  of  parameter  associ¬ 
ated  with  each  block  is  shown  in  the  Addendum. 

5.4.2.  Numeric  Parameters.  These  are  represented  with 
two’s  complement  encoding.  The  numbers  will  possibly  be 
followed  by  the  following  units  modifier  in  ASCII:  M  ( 4DH) 
for  million,  K  (4BH)  for  thousands,  m  ( 6DH)  for  thou¬ 
sandths,  and  u  (75H)  for  millionths.  If,  a  parameter  has  a 
possibility  of  being  modified  by  a  units  modifier,  a  modi¬ 
fier  will  always  be  required,  with  a  blank  character  signi¬ 
fying  no  multiplier.  Sixteen-  and  thirty- two-bit  integers 
with  modifiers  will  also  be  allowed  on  a  case-by-case 
basis. 

Unless  stated  otherwise  on  a  case  by  case  basis,  the  de¬ 
fault  unit  will  follow  the  SI  system. 

The  numeric  parameters  which  describe  angles  (heading, 
pitch,  etc.)  will  consist  of  two  bytes  and  will  represent 
the  angle  in  Binary  Angle  Measurement  (BAM) .  The  format  is 
unsigned,  16  bits,  MSB  =  180°,  LSB  =  180°/32,768.  Some 
examples:  The  binary  number  1000  0000  0000  0000  represents 

180°.  0100  0000  0000  0000  represents  90°.  0010  0000  0000 

0000  represents  45°.  0110  0000  0000  0000  represents  135°. 

1111  1111  1111  1111  represents  359.99°. 

5.4.3.  Select  Parameters.  These  are  used  when  we  need  to 
choose  one  or  more  options  from  a  group  of  choices. 

5.4.4.  Proportional  Intensity  Parameters.  These  are  used 
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to  represent  three  types  of  commands/status: 

•  Off,  incrementally  increasing  to  full  on. 

•  Down,  incrementally  rising  to  full  up. 

•  Straight  ahead,  incrementally  changing  to  full 
left  or  full  right. 

Greater  detail  is  required  for  the  parameters  on  a 
cases-by-case  basis.  This  detail  is  out  of  the  scope  of 
this  report. 

5.5.  Priority  Specification 

The  priority  of  different  messages  vary.  For  some  com¬ 
mands,  it  is  important  that  they  be  transmitted  as  soon  as 
they  are  made,  such  as  "Fire  the  Gun"  or  "Emergency 
Stop. "For  other  messages,  the  priority  is  lower,  such  as 
"Turn  on  bilge  pumps." 

Because  of  this,  each  message  may  be  assigned  a  priority  in 
the  protocol  software.  This  assignment  would  be  done  by 
the  system  developer.  The  transmission  of  high-priority 
commands  can  then  be  expedited. 

5.6.  Status  Information 

5.6.1.  Types.  There  are  three  types  of  status  information 
which  can  be  sent:  1)  Periodic,  2)  Solicited,  and  3) 
Unsolicited. 

5.6. 1.1.  Periodic.  This  type  of  status  is  continuously 
sent  at  a  regular  interval.  Periodic  status  information 
can  be  preprogrammed  (automatically  sent  periodically) ,  or 
a  request  can  be  made  to  start  supplying  certain  status 
periodically. 

A  command  requesting  periodic  status  has  in  its  Transaction 
Category  field  the  "periodic  status  request"  code  (010 
0) .  The  Block  Address,  Unit  ID,  and  Attribute  Identifier 
identify  what  status  is  being  requested. 

The  message  conveying  the  status  information  also  has  the 
"periodic  status  request"  code  in  its  Transaction  Category 
field. 

5. 6. 1.2.  Solicited.  This  type  of  status  is  sent  once  per 
request.  A  command  requesting  a  one-time  status  message 
has  in  its  Transaction  Category  field  the  "status  request" 
code  (0011).  The  Block  Address,  Unit  ID,  and  Attribute 
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Identifier  identify  what  status  is  being  requested. 

The  message  conveying  the  status  information  also  has  the 
"status  request"  code  in  its  Transaction  Category  field. 

5. 6. 1.3.  Unsolicited.  There  are  two  types  of  unsolicited 
status  information:  1)  Indication  and  2)  Alarm.  The 
former,  which  provides  an  update,  has  the  "indication"  code 
(1010)  in  its  Transaction  Category  field.  The  latter 
has  the  "alarm"  code  (1011)  in  its  Transaction  Category 
field. 


5.7.  General 


5.7.1.  Addition  of  New  Messages.  Currently,  only  31  out 
of  256  possible  Block  Addresses  and  12  out  of  256  possible 
Unit  IDs  have  been  used.  There  is  still  considerable  room 
for  growth. 

5.7.2.  Message  Lengths.  The  total  message  length  will  be 
limited  to  128  bytes.  This  is  done  to  minimize  the  trans¬ 
mission  latency  time.  A  message  size  of  128  bytes  limits 
the  latency  time  to  about  56  msec  at  19.2  kbps. 

5.7.3.  State  Attribute.  Many  devices  will  have  a  "state" 

attribute.  This  can  be  used  in  one  of  two  ways. 

The  first  way  it  can  be  used  is  to  turn  a  device  on  or  off. 

In  this  case,  a  message  has  an  "initiating"  Transaction 
Disposition  and  either  a  "control  no  acknowledgment"  or  a 
"control  with  acknowledgment"  Transaction  Category.  The 
Parameter  Bit  would  be  set  at  one  to  turn  the  device  on,  or 
at  zero  to  turn  the  device  off. 

The  second  way  that  the  state  attribute  can  be  used  is  to 

indicate  if  a  device  is  on  or  off.  A  device  can  do  this  if 

the  information  is  solicited,  or  it  may  do  so  because  its 
state  has  changed  for  some  reason. 

If  the  state  is  solicited,  the  return  message  describing 
the  state  will  have  a  "command  executed"  Transaction  Dispo¬ 
sition,  the  Parameter  Bit  will  be  used  to  describe  the 
state  (one  if  on,  zero  if  off) ,  and  the  other  fields 
(including  the  Transaction  Category  field)  will  stay  the 
same. 

If  the  state  is  not  solicited,  the  message  will  have  an 
"initiating"  Transaction  Disposition,  an  "indication" 
Transaction  Category  field,  and  the  Parameter  Bit  describ¬ 
ing  the  state. 
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5.1.  A.  Device  ID  Attribute.  Each  device,  identified  by  a 
unique  Block  Address  and  unit  ID,  will  have  as  its  first 
Attribute  Identifier  a  four-byte  identification  attribute. 
This  attribute  is  used  to  determine  the  different  charac¬ 
teristics  of  a  certain  device.  The  identification  at¬ 
tribute  itself  will  not  describe  the  characteristics. 
Instead  it  could  be  used  to  inform  a  control  station  to 
check  out  a  certain  table  which  describes  all  the  charac¬ 
teristics. 

For  example,  the  Destination  Address  may  say  that  the 
"front  camera"  unit  of  the  "mono  video  source"  block  is 
being  controlled.  But  the  controller  may  not  know  which 
attributes  can  be  remotely  controlled  (focus,  iris,  con¬ 
trast,  etc.)  since  many  different  cameras  will  be  used,  and 
are  being  used,  on  unmanned  ground  vehicles.  Having  an 
identification  attribute  provides  the  mechanism  for  a 
system  designer  to  make  his  software  automatically  query, 
at  start  up,  the  devices  being  controlled.  Based  on  the 
responses,  the  available  attributes  of  the  different  de¬ 
vices  can  be  determined. 

When  this  feature  is  used,  the  Transaction  Disposition 
would  be  "initiating."  The  Transaction  Category  would  be 
"status  request." 

Use  of  this  attribute  is  optional.  The  meaning  of  each 
identification  attribute  would  have  to  be  coordinated  by 
the  developer/user  of  the  control  station  and  of  the  un¬ 
manned  vehicle.  The  meaning  of  these  attributes  will  not 
be  further  defined  in  this  report. 

5.8.  Message  interactions 

5.8.1.  General.  This  section  describes  the  details  of  the 
initiating  transaction  and  the  responding  transaction  for 
different  transaction  types.  When  a  responding  message  is 
returned,  the  Transaction  Disposition  field  is  modified, 
along  with  parameters  according  to  the  different  situa¬ 
tions.  The  rest  of  the  fields  are  kept  the  same.  Also,  if 
one  or  more  of  the  Block  Address,  the  Unit  ID,  the  Transac¬ 
tion  Type,  or  the  Transaction  Attribute  is  unknown,  the 
Transaction  Disposition  will  be  set  to  Command  Unknown  and 
sent  back  with  the  parameter  field  describing  exactly  which 
field  is  unknown. 

5.8.2.  Message  Interactions. 

5. 8. 2.1.  Control  with  acknowledgment.  This  message  com¬ 
mands  some  function  be  performed,  and  requests  a  report  on 
the  actual  performance.  After  sending  the  message,  the 
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sender  will  set  up  a  timer.  Within  a  certain  time,  if  no 
responding  transaction  returns,  the  timer  will  time  out  and 
the  same  command  will  be  tried  n  times.  If  after  n  tries 
there  is  still  no  response,  the  timed-out  situation  will  be 
reported  to  the  application  software  which  in  turn,  may 
report  it  to  the  operator.  The  following  are  the  possible 
responses: 

•  Command  Received:  Normally,  if  a  command 
cannot  be  completed  within  0.5  seconds,  a  Command 
Received  response  will  be  sent  first.  Later, 
when  the  execution  finishes,  the  Command  Execu¬ 
tion  Indication  or  Command  Failed  Indication  will 
be  sent. 

•  Command  Executed:  If  a  command  can  be  executed 
within  0.5  seconds,  it  can  send  back  the  Command 
Executed  transaction  which  implies  that  the 
command  has  been  received. 

•  Command  Execution  Failed:  It  the  receiving 
system  is  unable  to  execute  a  command  it  re¬ 
ceived,  the  Command  Execution  Failed  response 
will  be  sent. 

•  Command  Unknown:  If  one  or  more  of  the  Block 
Address,  the  Unit  ID,  the  Transaction  Type,  or 
the  Transaction  Attribute  is  unknown,  the  re¬ 
sponse  will  be  the  Command  Unknown  Transaction 
Disposition.  The  parameter  field  will  describe 
exactly  which  field  is  unknown. 

5. 8. 2. 2.  Control  no  acknowledgment.  This  message  commands 
some  function  to  be  performed,  but  does  not  require  any 
acknowledgment.  After  this  message  is  sent  out,  no  response 
is  expected  unless  the  command  cannot  be  executed,  or  if  it 
is  unknown.  For  example,  during  teleoperation,  if  a  driver 
pushes  the  brake  pedal,  the  brake  commands  will  be  sent  to 
the  RV  using  Control  No  Acknowledgment  transactions.  The 
driver  gets  direct  feedback  by  seeing  the  vehicle  slowing 
down.  The  following  are  the  possible  responses: 

•  Command  Execution  Failed 

•  Command  Unknown 

5. 8. 2. 3.  Status  request.  This  Transaction  Type  requests  a 
report  on  the  status  of  a  device  or  module.  If  no  response 
is  returned  from  the  RV  within  a  certain  time  (time  to  be 
determined),  the  message  will  be  retried  n  times  (n  to  be 
determined).  If  after  n  tries  no  response  is  returned,  the 
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time  out  situation  will  be  reported  to  the  application 
software  and  possibly  to  the  operator.  The  following  are 
the  possible  responses: 

•  Command  Executed 

•  Command  Execution  Failed 

•  Command  Unknown 

5.8. 2.4.  Periodic  status  request.  This  Transaction  Type 
asks  for  a  report  on  the  status  of  a  device  or  module  oh  a 
periodic  basis.  The  first  acknowledgment  returned  indicates 
a  mechanism  has  been  set  up  to  report  the  requested  status 
periodically.  If  no  Command  Executed  response  is  returned 
within  a  certain  time,  the  request  will  be  made  n  more 
times,  if  no  response  is  returned  after  n  tries,  the 
timed-out  situation  will  be  reported  to  the  application 
software  and  possibly  to  the  operator.  If  the  Periodic 
Status  Request  is  executed  successfully,  the  RV  will  con¬ 
tinue  to  send  the  desired  information  at  the  requested  rate 
until  it  receives  a  cancellation  command.  A  command  with 
the  update  rate  set  to  zero  is  considered  to  be  a  cancella¬ 
tion  command.  The  following  are  the  possible  responses: 

•  Command  Execution  Failed 

•  Command  Unknown 

•  Command  Executed 

5. 8. 2. 5.  Query  control.  This  Transaction  Type  can  be  used 
to  verify  that  an  attribute  is  modifiable  without  causing 
any  action.  If  no  response  is  returned  within  a  certain 
time,  the  message  will  be  sent  n  times  before  it  gives  up. 
If  there  is  no  response  returned  after  n  tries,  the  timed- 
out  situation  will  be  reported  to  the  application  software 
and  possibly  to  the  operator.  The  following  are  the  possi¬ 
ble  responses: 

•  Command  Executed 

•  Command  Unknown 

5. 8. 2.6.  Set  alarm  limits.  This  Transaction  Type  sets  the 
upper  and  lower  limits  for  alarms.  The  parameter  field 
contains  the  limits.  If  no  response  is  returned  within  a 
certain  time,  the  message  will  be  sent  n  times.  If  there 
is  no  response  returned  after  n  tries,  the  timed-out  situa¬ 
tion  will  be  reported  to  the  application  software  and 
possibly  to  the  operator.  The  following  are  the  possible 
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responses. 

•  Command  Executed 

•  Command  Execution  Failed 

•  Command  Unknown 

5. 8. 2. 7.  Query  alarm  limits.  This  Transaction  Type  asks 
for  a  report  on  the  actual  alarm  limits  as  set  or  the 
allowed  range  of  the  attribute.  In  the  latter  case,  if  the 
software  has  set  a  range  for  alarm  limits,  it  reports  the 
range  limits.  Otherwise,  it  reports  the  hardware  alarm 
limits.  If  no  response  is  returned  within  a  certain  time, 
the  message  will  be  sent  n  times.  If  there  is  no  response 
returned  after  n  tries,  the  timed-out  situation  will  be 
reported  to  the  application  software  and  possibly  to  the 
operator.  The  following  are  the  possible  responses: 

•  Command  Executed 

•  Command  Unknown 

5. 8. 2. 8.  Set  operating  limits:  This  transaction  sets  the 
upper  and  lower  limits  of  an  operating  parameter.  If  no 
response  is  returned  within  a  certain  time,  the  message 
will  be  sent  n  times.  If  there  is  no  response  returned 
after  n  tries,  the  timed-out  situation  will  be  reported  to 
the  application  software  and  possibly  to  the  operator.  The 
following  are  the  possible  responses: 

•  Command  Executed 

•  Command  Execution  Failed 

•  Command  Unknown 

5. 8. 2. 9.  Query  operating  limits.  This  Transaction  Type 
asks  for  a  report  on  either  the  actual  operating  limits  or 
the  range  limits  of  the  attribute.  In  the  latter  case,  if 
the  software  has  defined  the  operating  range  limits,  it 
reports  those  limits.  Otherwise,  it  reports  the  hardware 
operating  limits.  If  no  response  is  returned  within  a 
certain  time,  the  message  will  be  sent  n  times.  If  there 
is  no  response  returned  after  n  tries,  the  timed-out  situa¬ 
tion  will  be  reported  to  the  application  software  and 
possibly  to  the  operator.  The  following  are  the  possible 
responses: 

•  Command  Executed 
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•  Command  unknown 


5.8.2.10.  Indication.  The  Indication  message  is  sent  to 
declare  that  some  status  has  changed.  The  message  will  be 
continually  sent  until  an  acknowledgment  is  received.  The 
response  is: 

•  Command  Received:  The  transaction  is  returned 
with  the  Transaction  Disposition  changed,  and 
without  any  parameter. 

5.8.2.11.  Alarm  Activated.  An  Alarm  message  is  sent  when 
some  critical  condition  is  present.  The  message  will  be 
continually  sent  until  an  acknowledgement  is  received.  The 
response  is: 

•  Command  Received:  The  transaction  is  returned 
with  the  Transaction  Disposition  changed,  and 
without  any  parameter. 

5.8.2.12.  Alarm  retired.  This  message  is  sent  to  declare 
that  the  previously  reported  critical  condition  has  re¬ 
turned  to  normal.  This  message  will  be  continuously  sent 
until  it  gets  an  acknowledgment.  The  response  is: 

•  Command  Received:  The  transaction  is  returned 
with  the  Transaction  Disposition  changed,  and 
without  any  parameter. 

5.9.  Message  Development 

A  general  methodology  to  develop  messages  using  the  RVMF 
follows . 

The  numerical  code  for  each  field  should  be  identified. 

•  The  Block  Address,  Unit  ID,  and  Transaction 
Attribute  of  each  function  are  taken  from  the 
Addendum. 

•  The  source  address  is  set  by  the  software.  If 
the  message  is  a  response  to  a  previous  message, 
the  Destination  Address  and  the  Source  Address 
are  simply  switched.  What  was  formerly  the 
Source  Address  is  now  the  Destination  Address. 

This  guarantees  that  the  proper  module  is  ac¬ 
knowledged. 

•  The  Transaction  Type  can  be  found  in  sections 
5.3.3.  and  5.3.4.  of  this  report. 
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•  The  Sequence  Number  is  a  four-bit  number. 

There  is  not  a  sequential  correspondence  between 
different  Sequence  Numbers  in  the  same  Submessage 
or  Message.  The  only  correspondence  is  between 
the  Sequence  Number  of  an  initiating  transaction 
and  that  of  a  responding  transaction. 

•  The  value  of  the  Parameter  Bit  and  the  Parame¬ 
ter  field  are  dependent  on  the  transaction. 

Once  the  value  tor  each  field  is  obtained,  the  transactions 
should  be  grouped  as  submessages  (any  transactions  with  the 
same  Block  Address  and  the  same  Unit  ID) .  The  Submessage 
Length  field  can  now  be  determined. 

The  last  step  is  to  group  all  the  submessages,  and  to 
determine  a  value  for  the  Message  Length  field. 

5.10.  Examples 

Examples  are  now  presented  in  order  to  clarify  how  the 
message  format  works. 

5.10.1.  Example  1.  Personnel  in  a  control  station  are 
remotely  driving  (full  throttle,  straight  steer)  an  un¬ 
manned  vehicle,  are  turning  on  the  headlights,  and  are 
requesting  status  as  to  how  much  fuel  remains  in  the  main 
fuel  tank. 

Following  the  methodology  described  in  section  5.9,  the 
values  for  the  initial  fields  can  be  determined.  They  are 
shown  on  the  chart  on  the  following  page. 

After  putting  in  the  values  on  the  chart,  group  the  com¬ 
mands  as  submessages.  Since  each  command  has  a  different 
Block  Address  and  Unit  ID,  each  command  is  a  separate 
submessage. 

Next  determine  the  values  for  the  Submessage  Length  fields. 
All  four  commands  have  seven  fields:  1)  Submessage  Length, 
2)  Block  Address,  3)  Unit  ID,  4)  Source  Address,  5)  Se¬ 
quence  Number,  6)  Transaction  Type,  and  7)  Transaction 
Attribute.  These  seven  fields  occupy  eight  bytes.  In 
addition,  the  throttle  and  steering  commands  each  have  a 
one-byte  Parameter  field.  The  Submessage  Length  values 
are: 

Throttle  09H  Lowbeam  light  08H 

Steering  09H  Fuel  status  08H 

The  last  value  to  be  determined  is  the  Message  Length. 
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This  is  simply  the  sum  of  the  Submessage  Length  values, 
plus  one  for  the  Message  Length  field  itself.  The  value  is 
09H  +  09H  +  08H  +  08H  +01H  =  23H  (3510) . 

The  complete  message  is: 


23  09  02 

01  xx  xx  50 

02  0A  FF 

09  04  01  xx 

xx  20  02 

04  00 

08  14  02 

xx  xx  A0  02 

05  08  06 

01  xx  xx  40 

03  04 

Note  that  xx  xx  depicts 

the  Source  Address. 

Command : 

Throttle 

Steer 

Headlights  Fuel 

level 

Block 

Name: 

Power  plant  Steering  Lights 

Fuel 

Block 

Address: 

02H 

04H 

14H 

06H 

Unit  ID: 

Main 

Engine 

Steering 

Low  beam 

lights  Fuel  tank 

A 

Unit 

Address : 

01H 

01H 

0  2h 

01H 

Sequence 
Number : 

5H 

2H 

AH 

4H 

Transaction 

Disposition: 

:  0H 

0H 

0H 

0H 

Transaction 

Category: 

02H 

02H 

02H 

03H 

Transaction 

Attribute: 

Throttle 

Setting 

State 

Level  gauge 

Attribute 
Identifier : 

05H 

02H 

02H 

02H 

Parameter 

Bit: 

NA  (0) 

NA  (0) 

1 

NA  (0) 

Attribute 

Field: 

0000  1010 

0000  0100 

0000  0101 

0000  0100 

Parameter: 

FF  (full) 

00  (straight)  NA 

NA 

5.10.2.  Example  2.  This  is  a  message  sent  from  an  un¬ 
manned  vehicle  to  the  control  station.  It  is  sent  after 
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the  receipt  of  the  message  described  in  section  5.10.1. 

The  message  gives  the  engine  RPM,  the  fuel  level,  the 
vehicle  speed,  and  an  alarm  that  a  chemical  agent  has  been 
detected. 

Again,  the  methodology  described  in  section  5.9  will  be 
used  to  determine  the  values  for  the  different  fields. 

They  are  shown  on  the  chart  on  this  page. 


Command : 

RPM 

Fuel  level 

Speed 

Alarm 

Block 

Name :  j 

Power  plant 

Fuel 

Navigation 

Sensors 

Block 

Address: 

02H 

06H 

10H 

19H 

Unit  ID: 

Main 

Engine 

Tank  A 

Main 

Chemical 

Unit 

Address: 

01H 

01H 

01H 

03H 

Sequence 
Number : 

6H 

4H 

7H 

2H 

Transaction 

Disposition 

:  2H 

2H 

2H 

0H 

Transaction 

Category: 

04H 

03H 

04H 

0BH 

Transaction 

Attribute: 

RPM 

Level 

Speed 

Alarm 

Attribute 

Identifier: 

0000  100 

0000  010 

0001  000 

0000  100 

Parameter 

Bit: 

NA  (0) 

NA  (0) 

NA  (0) 

1 

Attribute 

Field: 

08H 

04H 

10H 

09H 

Parameter: 

80H  (half) 

40H  (1/4  tank)  C0H 

yy  yy 

Note  that  the  Sequence  Number  for  the  "fuel  tank  level” 
transaction  above  is  the  same  as  the  Sequence  Number  for 
the  "request  for  fuel  tank  level  status"  transaction  in  the 
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first  example. 

Now  group  the  commands  as  submessages.  Since  each  command 
has  a  different  Block  Address  and  Unit  ID,  each  command  is 
a  separate  submessage. 

Next  get  the  values  for  the  Submessage  Length  fields.  All 
four  commands  have  eight  fields:  1)  Submessage  Length,  2) 
Block  Address,  3)  Unit  ID,  4)  Source  Address,  5)  Sequence 
Number,  6)  Transaction  Type,  7)  Transaction  Attribute,  and 
8)  Parameter  field.  The  Submessage  Length  values  are: 

RPM  09H  Speed  09H 

Fuel  09H  Chemical  alarm  0AH 

The  last  value  to  be  determined  is  the  Message  Length. 

This  is  simply  the  sum  of  the  Submessage  Length  values, 
plus  one  for  the  Message  Length  field  itself.  The  value  is 
09H  +  09H  +  09H  +  0AH  +01H  =  26H  (3810) . 

The  "fuel  tank  level"  transaction  is  a  response  to  the 
request  in  the  first  example  for  that  information.  The 
"powerplant  RPM"  and  the  "navigation  speed"  transactions 
are  responses  to  previous  requests  for  periodic  status. 
Therefore,  the  original  Source  Addresses,  depicted  by  xx 

xx,  are  now  in  the  Destination  Address  fields,  and  the 

original  Destination  Addresses  are  now  in  the  Source  Ad¬ 
dress  fields. 

The  complete  message  is: 

26  09  xx  xx  02  01  62  04  08  80  09  xx  xx  06  01  42  03  04  40 

09  xx  xx  10  01  72  04  10  C0  0A  19  03  xx  xx  20  0B  09  yy  yy 

Note  that  yy  yy  depicts  the  value  of  the  attribute,  and  the 
applicable  error  code. 

5.10.3.  Example  3.  This  is  a  message  sent  from  a  control 
station  to  an  unmanned  vehicle.  The  commands  tell  the 
vehicle  to  come  to  a  complete  halt  (full  brake,  zero  throt¬ 
tle)  ,  to  power  up  the  weapons  platform,  and  to  send  vehicle 
attitude  data  (roll,  pitch). 

Again,  the  methodology  described  in  section  5.9  will  be 
used.  Because  of  the  length  of  this  message,  two  charts 
will  be  needed.  They  are  shown  on  the  following  two  pages. 

After  putting  in  the  values  on  the  chart,  group  the  com¬ 
mands  as  submessages.  The  first  three  commands  each  have  a 
different  Destination  Address,  so  each  command  is  a  sepa- 


27 


rate  submessage.  The  last  two  commands  have  an  identical 
Destination  Address,  so  they  will  be  grouped  as  one  submes¬ 
sage. 

Next  get  the  values  for  the  Submessage  Length  fields.  The 
first  three  commands  have  seven  fields:  1)  Submessage 
Length,  2)  Block  Address,  3)  Unit  ID,  4)  Source  Address,  5) 
Sequence  Number,  6)  Transaction  Type,  and  7)  Transaction 
Attribute.  In  addition,  the  throttle  and  braking  commands 
each  have  a  one-byte  Parameter  field.  The  last  two  com¬ 
mands  share  the  same  Submessage  Length,  Block  Address,  Unit 
ID,  and  Source  Address  fields,  but  have  separate  Sequence 
Numbers,  Transaction  Types,  and  Transaction  Attributes. 


Command : 

Full  brake 

Zero  throttle 

Platform 

Block 

Name: 

Brakes 

Powerplant 

Movable 

platform 

Block 

Address: 

03H 

02H 

18H 

Unit  ID: 

Regular 

Engine 

Weapon 

Unit 

Address: 

01H 

01H 

02H 

Sequence 
Number : 

AH 

BH 

CH 

Transaction 

Disposition: 

0H 

0H 

0H 

Transaction 

Category: 

02H 

02H 

01H 

Transaction 

Attribute: 

Setting 

Throttle 

State 

Attribute 
Identifier : 

0000  010 

0000  101 

0000  010 

Parameter 

Bit: 

NA  (0) 

NA  (0) 

1 

Attribute 

Field: 

04H 

0AH 

05H 

Parameter : 

FFH  (full) 

00H  (zero) 

NA 
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Command : 

Request  roll 

Request  pitch 

Block 

Name: 

Navigation 

Navigation 

Block 

Address: 

10H 

10H 

Unit  ID: 

Main 

Main 

Unit 

Address: 

01H 

01H 

Sequence 

Number : 

9H 

AH 

Transaction 
Disposition : 

0H 

0H 

Transaction 

Category: 

03H 

03H 

Transaction 

Attribute: 

Roll 

Pitch 

Attribute 
Identifier : 

0000  101 

0000  110 

Parameter 

Bit: 

NA  (0) 

NA  (0) 

Attribute 

Field: 

0AH 

0CH 

Parameter : 

NA 

NA 

The  Submessage  Length  values  are: 

Brake  09H  Platform  power  08H 

Throttle  09H  Navigation  info  0BH 

The  last  value  to  be  determined  is  for  the  Message  Length. 
This  is  simply  the  sum  of  the  Submessage  Length  values, 
plus  one  for  the  Message  Length  field  itself.  The  value  is 
09H  +  09H  +  08H  +  0BH  +01H  =  26H  (3810) . 

The  complete  message  is: 

26  09  03  01  xx  xx  A0  02  04  FF  09  02  01  xx  xx  70  02  0A  00 
08  18  02  xx  xx  C0  01  05  0B  10  01  xx  xx  90  03  0A 
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A0  03  0C  B0  03  0E 


Note  that  xx  xx  depicts  the  Source  Address. 

5.10.4.  Example  4.  This  is  a  message  sent  from  an  un¬ 
manned  vehicle  to  the  control  station.  It  is  sent  after 
the  receipt  of  the  message  described  in  section  5.10.3.  It 
returns  status  information  requested  of  the  navigation 
system.  Note  that  the  acknowledgment  of  the  powering  up  of 
the  movable  weapon  platform  is  not  in  this  message.  This 
is  because  the  responses  to  commands  and  requests  packed 
into  the  same  initiating  message  will  not  necessarily  be 
packed  in  the  same  responding  message. 

Again,  the  methodology  described  in  section  5.9  will  be 
used.  The  values  for  the  initial  fields  are  determined, 
and  are  shown  on  the  chart  on  the  following  page. 

After  putting  in  the  values  on  the  chart,  group  the  mes¬ 
sages  as  submessages.  The  two  navigation  messages  can  be 
grouped  as  a  single  submessage. 

Next  get  the  value  for  the  Submessage  Length  field.  The 
submessage  has  four  fields:  1)  Submessage  Length,  2)  Block 
Address,  3)  Unit  ID,  and  4)  Source  Address.  Each  of  the 
two  transactions  has  its  own  Sequence  Number,  Transaction 
Type,  Transaction  Attribute,  and  a  two-byte  Parameter 
field. 

Navigation  0FH 

The  last  value  to  be  determined  is  for  the  Message  Length. 
This  is  simply  the  Submessage  Length  value,  plus  one  addi¬ 
tional  byte  for  the  Message  Length  field  itself.  The  value 
is  0FH  +  01H  =  10H  (1610) . 

As  in  the  second  example,  the  original  Destination  Address 
will  now  be  in  the  Source  Address  field.  Likewise,  the 
original  Source  Address,  depicted  by  xx,  will  now  be  in  the 
Destination  Address  field.  Also,  note  that  the  Sequence 
Numbers  correspond  to  the  Sequence  Numbers  in  Example  2 . 

The  complete  message  is: 

10  0F  xx  xx  10  01  92  03  0A  04  00  A2  03  0C  40  00 

Note  that  xx  xx  depicts  the  original  Source  Address. 


30 


Command : 

Block 

Name: 

Block 
Address : 

Unit  ID: 

Unit 

Address: 

Sequence 
Number : 

Transaction 

Disposition 

Transaction 

Category: 

Transaction 

Attribute: 

Attribute 
Identifier : 

Parameter 

Bit: 

Attribute 

Field: 

Parameter : 


Roll 

Status 

Navigation 

0AH 

Main 

01H 

9H 

2H 

03H 

Roll 

0000  101 

NA  (0) 

0AH 

04  00H  (2.8°) 


Pitch 
Status 

Navigation 

0AH 

Main 

01H 

AH 

2H 

03H 

Pitch 

0000  110 

NA  (0) 

0CH 

40  00H  (45°) 
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ADDENDUM 
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